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Abstract 


The web-based IETF email archive search tool based on the 
requirements captured in RFC 6778 was deployed in January 2014. This 
memo captures the requirements for a set of improvements that have 
been identified during its initial years of community use. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7842. 


Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 
The IETF email archive search tool, as specified in [RFC6778]) and 
available at [mailarch], has been in use for nearly two years. 
During that time, there have been repeated requests for several 
improvements. This memo captures the requirements for a concerted 
development effort to provide those improvements. 
2. List Search and Archive Tool Improvement Requirements 
2.1. Viewing by Thread 
Currently, when the "Group by Thread" button is selected, the 
resulting list of messages is flat. It is very hard to tell where a 
thread starts and stops. This flat view interacts badly with sorting 


(triggered by clicking on the column headers), leading to results 
that are confusing and sometimes incorrect. 


This effort will: 


(0) 


Sparks 


Modify the message list display, when grouped by thread, to show 
each thread hierarchically. 


Modify the sort performed by the clicking on the column headers to 
sort the overall list first by the parameters in the first message 
in the thread, and then sort within the thread (ensuring the 
thread grouping doesn’t change based on these sorts). When 
viewing threads sorted this way, the hierarchy will be flattened, 
but the thread boundaries will remain visibly distinct. 
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2.2. Navigation from the Message List View 


This effort will add navigation to the message list view, whether 
viewing flat search results or viewing by thread, making it simple 
to: 


o Navigate to the previous/next message by date in the set of listed 
messages. 


o Navigate to the previous/next message in a thread, to the first 
message in a thread, and to the previous/next thread displayed. 


o Navigate to any References or Replies (displayed as Follow-Ups in 
MHonArc) for the currently selected message. These are derived 
from the References header field in the displayed message, and the 
In-Reply-To header field or the last value in the References 
header field of all other messages in the archive). 


The UI will make it possible to hide these navigation elements. 
2.3. Navigation from a Single Message 


Currently, when viewing a single message, the only option for 
navigating to related messages is to return to the message list view 
(either by date or by thread). This is implemented with a new search 
based only on the details present in the message itself. No 
information about any search that led to the message is retained. 


This effort will: 


o Add navigation to the single message view, enabling transition to 
previous/next in list and previous/next in thread. 


o Add navigation enabling transition to previous/next in search, if 
the message page being displayed was arrived at by navigating from 
the message list view of a search result. 


o Add navigation to any References or Replies (displayed as Follow- 
Ups in MHonArc). These are derived from the References header 
field in the displayed message, and the In-Reply-To header field 
or the last value in the References header field of all other 
messages in the archive. 


o Make it possible to hide these navigation elements. 
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2.4. Message List UI 


It is not sufficiently obvious that the message list panel can be 
resized. The current handle is not visually distinct enough to 
signal the capability to the user, leaving many users believing they 
are restricted to the very short default list, even when viewing on 
large monitors. 


Additionally, there is a flaw in the code that fetches additional 
messages when scrolling to the bottom of what’s currently displayed. 
If the message window is large enough that the default number of 
results does not fill it, no scrollbar appears, and scrolling to the 
bottom does not fetch additional results. 


The filter by list and filter by from sections to the left of the 
message list have no values in many circumstances, but it is not 
obvious why they are missing. One notable condition is when the 
search result is very large -- computing the values to put in these 
filters becomes prohibitively expensive. Without foreknowledge of 
the decisions captured in the code, the behavior seems arbitrary and 
unintuitive. 


The current view truncates fields, leaving trailing ellipses, when it 
doesn’t need to. This leaves space underutilized on large displays 
and may make selection (particularly of long email addresses in the 
filters) much more difficult than it should be. On small displays, 
the column of filters dominates the display, leaving only a small 
amount of space for the actual message content. 


The current view requires the user to select each message in the 
message list to get the URI to that message. This makes it difficult 
to open several messages in different windows, or to build a list of 
URIs for use in a message or other applications. It is also not 
obvious that double-clicking a row in the list will open the message 
in a separate window. 


This effort will: 


o Make the ability to resize the panels on the message list display 
easier to find. 


o Account for the size of the message list panel when choosing how 
many messages to fetch, filling the panel whenever there are 
enough results to do so. 


o Provide a message explaining any condition leading to filter 


values not being populated (such as "Refine search to enable 
‘From’ filtering"). 
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o Allow subjects to fill the column on large displays. Show fully 
expanded list and email addresses in the pop-ups for the filters. 


o Provide a link on each row of the list to the URL for that row’s 
message. 


o Add an export type that produces a file containing a list of URIs 
to each message in the list. 


o Add a hint to the UI that double-clicking on a row in the list 
will open a single-message view of the associated message in a 
separate view. 


2.5. Improve Support for Mobile Devices 


The current view becomes difficult to use on small displays, 
particularly phone displays in portrait mode. This effort will: 


o Add a responsive interface, presenting a useful interface on both 
small and large displays. 


2.6. Improve Use of Display Space 


The current view underutilizes the available display space. This 
effort will: 


o Make the message content the primary point of each view. 


o Reduce the unused space on the display. 


o Remove the filter column responsively when the display width is 
small. 


2.7. Use without JavaScript 
The current web-based archive search tool requires JavaScript to 
function. This effort will extend the tool to allow users that have 
disabled JavaScript in their browser to retrieve and navigate through 
search results using the message list and single message views. 
This effort will not attempt to preserve all of the functionality 
provided with JavaScript enabled. In particular, when running with 
JavaScript disabled, these features will not be available: 


o Resizing of the message list panels. 


o Dynamically filtering by time, list, or from. (The filter column 
will not appear). 
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2.8. Administration 
This project will: 


o Add a link from the message view to the admin page for the message 
when logged in as an administrator. 


o Add correction of the appropriate thread indices to the handling 
of administrative imports of messages. 


o Implement a redirection handler mapping legacy archive URLS to the 
appropriate mailarch page. 


o Make the underlying template consistent across all views presented 
by the tool. In particular, ensure that the correct logo as 
designated by the IETF Administrative Oversight Committee (IAOC) 
appears consistently on all views. 


3. Security Considerations 
The requirements for improvement to the mailarch tool captured in 
this document do not introduce any exceptional security 
considerations. They add additional navigation points, and the 
implementers should consider the impact of rapid navigation using 
these new mechanisms (see the security considerations of [RFC6778]). 
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